Amazon Elasticsearch Serviceでバージョン1.5から2.3へ移行する

藤本真司

2016.08.16

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、藤本です。

先日のエントリ「Amazon Elasticsearch ServiceでElasticsearch 2.3が利用可能になりました」にて、Elasticsearch 2.3についてご紹介しました。今回は既存の1.5から2.3に移行する方法をご紹介します。

移行手順

移行手順はAWSのドキュメント、および日本語記事でもAWS SAブログでご紹介されています。

手順は非常にシンプルです。

Migrationプラグインによるチェック
バージョン1.5のドメインによるSnapshot取得
バージョン2.3のドメイン作成
バージョン2.3のドメインに取得したSnapshotからRestore
アプリケーションテスト
（Option）バージョン1.5のドメイン削除

Migrationプラグイン

MigrationプラグインはElasticのGithubリポジトリで開発されているマイグレーションのチェックツールとなります。

Elasticsearch Migration Plugin

1系から2系にかけていくつかのクラスタやインデックス設定において廃止や非推奨となっている項目があります。これらの項目を実際のElasticsearchの設定値を読み取ってチェックします。それにより1.5から2.3に正常にデータ移行が可能かを判断することができます。

ただし、Migrationプラグインのチェック範囲はクラスタ、インデックス、マッピング、セグメントに限定されています。MigrationプラグインがOKだからといって移行しても、アプリケーションが引き続き正常に動作することは担保されません。移行によるアプリケーションのテストは必ず行ってください。

チェック結果

Migrationプラグインは4レベルでチェック結果を通知します。

Green

問題なし

Blue

アドバイザリーの表示

Yellow

移行は可能だが、非推奨の項目あり

Red

移行するためには修正が必要

チェック項目

チェック項目はChecks performedをご参照ください。

導入方法

先のブログでもご紹介しましたが、Amazon Elasticsearch Serviceのバージョン1.5をご利用中の方はMigrationプラグインが自動的にインストールされています。

# curl search-es15-**************.ap-northeast-1.es.amazonaws.com/_cat/plugins
Hawkeye jetty NA j
Hawkeye cloud-aws ${project.version} j
Hawkeye analysis-kuromoji 2.5.1-SNAPSHOT j
Hawkeye analysis-icu 2.5.0 j
Hawkeye kibana NA s /_plugin/kibana/
Hawkeye migration NA s /_plugin/migration/
Hawkeye kibana3 NA s /_plugin/kibana3/

やってみた

Migrationプラグインによるチェック

Webブラウザを開いて、http://Elasticsearch_domain_endpoint/_plugin/migrationへアクセスします。ElasticsearchドメインのAccess Policyで制限されていると、Kibana同様、アクセスできませんのでご注意ください。

elasticsearch_migration_checker_v0_17-AESpatch

入力項目は4つです。左のテキストボックスには対象となるエンドポイントを入力してください。デフォルトでElasticsearchドメインのエンドポイントが設定されています。右のテキストボックスは対象となるインデックス名（パターン）を入力してください。全てのインデックスを対象とする場合は入力不要です。左のチェックボックスはクローズしているインデックスを含めるか否か、右のチェックボックスはベーシック認証が必要か否かです。AmazonESの場合、ベーシック認証は不要となります。

以上の設定後、「Run checks now」ボタンを押下してください。

結果は画面下部に表示されます。「Show green test result」をチェックすることで結果がGreenの項目も含めて全て表示されます。今回はKibanaのインデックスしか用意していなかったため、全てGreenとなっています。

elasticsearch_migration_checker_v0_17-AESpatch 2

NGの場合

Blue/Yellow/Redが表示される例も見てみましょう。

elasticsearch_migration_checker_v0_17-AESpatch 3

結果はRedが表示されているため、データ移行前にRedを解消する必要があります。それぞれを説明します。

Murmur3 (Red)
Elasticsearch 2.0からmurmur3タイプはPlugin化されました。Amazon Elasticsearch ServiceではPluginのインストールをサポートしていないため、実質利用不可となりました。Murmur3のフィールドは除外などする必要があります。
Type name: length (Yellow)
Elasticsearch 2.0からタイプ名の最大文字数が255文字となりました。
Type name: initial dot (Yellow)
Elasticsearch 2.0からタイプ名の先頭に.(ドット)を利用できなくなりました。
Boolean fields (Blue)
Elasticsearch 2.0からbooleanタイプのフィールドはスクリプト、Aggregation、ソートにおいてT/Fではなく、1/0を返します。アプリケーションなどで実装している場合、アプリケーションの変更が必要になります。

バージョン1.5のドメインによるSnapshot取得

Working with Manual Index Snapshots (AWS CLI)の手順に従って、S3へSnapshotを取得します。Amazon ESは毎日自動でSnapshotを取得していますが、自動Snapshotに関してはユーザーが利用できないため、手動でS3へSnapshotを取得する必要があります。

IAM Role作成

AmazonESがS3へアクセスできるようにIAM Roleを作成します。

Trusted Relationship

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "es.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}

Permissions (Inline Policy)

{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::"
]
},
{
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject",
"iam:PassRole"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::/*"
]
}
]
}

Snapshotリポジトリ作成

AWSリクエスト署名なしのSnapshotリポジトリ作成APIはサポートされていません。以前のエントリの方法やドキュメントに記載のスクリプトで署名つきAPIを発行します。

# python

>>> from botocore.awsrequest import AWSRequest
>>> from botocore.auth import SigV4Auth
>>> from botocore.endpoint import PreserveAuthSession
>>> from botocore.credentials import Credentials

>>> url='http://search-es15-**************.ap-northeast-1.es.amazonaws.com/_snapshot/migration'
>>> data='{"type": "s3","settings": {"bucket": "","region": "ap-northeast-1","role_arn": "arn:aws:iam::123456789012:role/"}}'

>>> credentials = Credentials("", "", "")
>>> request = AWSRequest(method='POST', url=url, data=data)
>>> SigV4Auth(credentials, 'es', "").add_auth(request)
>>> PreserveAuthSession().send(request.prepare())

Snapshot取得

Snapshotを取得します。

# curl -XPUT "http://search-es15-************.ap-northeast-1.es.amazonaws.com/_snapshot/migration/20160815"
{"accepted": true}

Snapshotリポジトリに登録したS3バケット内にSnapshotファイル群が生成されています。

S3_Management_Console

バージョン2.3のドメイン作成

バージョン2.3のAmazon ESドメインを作成します。ドメイン作成手順は[新機能]Amazon Elasticsearch Serviceがリリースされました！をご参照ください。

バージョン2.3のドメインに取得したSnapshotからRestore

Snapshot取得時同様、バージョン2.3のドメインにSnapshotリポジトリを登録します。

次にSnapshotからリストアします。

# curl -XPOST "http://search-es23-****************.ap-northeast-1.es.amazonaws.com/_snapshot/migration/20160815/_restore"
{"accepted": true}

今回はbankというドキュメント数1000件のインデックスを移行しました。

# curl -XGET "http://search-es23-*************.ap-northeast-1.es.amazonaws.com/_cat/indices"
yellow open bank 5 1 1000 0 417.5kb 417.5kb

正常にデータが移行されました。

アプリケーションテスト

一通りアプリケーションテスト行ってください。

こちらで悩むのがElasticsearchはDeprecation Loggingを実装しており、非推奨となっている設定やAPIを送るとログに記録してくれます。

例えば`filtered` Query

# curl -XGET "http://localhost:9200/bank/_search" -d'
{
"query": {
"filtered": {
"query": {
"match": { "age": 30 }
}
}
}
}'
:

# tail /var/log/elasticsearch/elasticsearch_deprecation.log
[2016-08-15 06:50:51,941][DEBUG][deprecation.index.query ] The [filtered] query is deprecated, please use a [bool] query instead with a [must] clause for the query part and a [filter] clause for the filter part.

Amazon ESのドメインはAWSマネージドサービスのため、ログを確認することができません。そういった意味でもアプリケーションテストは念入りに行うべきでしょう。